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DETAILED ACTION 

1 . The amendment filed 5/1 8/2006 has been placed of record in the file. 

2. Claims 2-4, 8, 19-22, 29, 30, 35, 36, 39, 41, 48, 49, and 51 have been amended. 

3. Claims 1-5, 8-14, 18-25, 29, 30, 34-41, 43, and 45-53 are now pending. 

4. The applicant's arguments with respect to claims 1-5, 8-14, 18-25, 29, 30, 34-41, 43, and 
45-53 have been fully considered but they are not persuasive. A detailed discussion is set forth 
below. 

Continued Examination Under 37 CFR LI 14 

5. A request for continued examination under 37 CFR 1.114, including the fee set forth in 
37 CFR 1.17(e), was filed in this application after final rejection. Since this application is 
eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) 
has been timely paid, the finality of the previous office action has been withdrawn pursuant to 37 
CFR 1.114. The applicant's submission filed on 2/27/2006 has been entered. 

Response to Amendment 

6. Claims have been amended to state the use of a TCP/IP protocol stack. This limitation 
was previously already present in many of the claims and had already been taken into 
consideration when applying the previous grounds of rejection. 
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Claim Rejections - 35 USC § 103 

7. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

8. Claims 1-5, 8-14, 22, 24, 25, 29, 30, 34-37, 39, 41, 43, 45, 47-50, 52, and 53 are rejected 
under 35 U.S.C. 103(a) as being unpatentable over Lucovsky (U.S. Patent Number 6,868,450) in 
view of Jackowski et al. (U.S. Patent Number 6,141,686), hereinafter referred to as Jackowski. 

9. Lucovsky disclosed a system for packet filtering based on a process attribute. In an 
analogous art, Jackowski disclosed a system for packet classification based on high-level 
applications. 

10. Concerning claims 1, 10, 22, 25, 30, 34, 36, 37, 39, 41, 43, 45, 48, 49, and 53, Lucovsky 
did not explicitly state a look-ahead function being executed within a protocol stack including an 
IP layer, a transport layer, a sockets layer, and an application layer and which, for said inbound 
packet, said IP layer provides to said transport layer said inbound packet and receives back from 
said transport layer indicia, provided to said transport layer by said sockets layer, identifying the 
application layer application to which said packet would have been delivered. However, 
Jackowski does explicitly disclose this feature as his system uses an extensible service provider 
within the stack to identify high-level applications. It would have been obvious to one of 
ordinary skill in the art at the time of the applicant's invention to modify the system of Lucovsky 
by adding the ability to utilize a look-ahead function being executed within a protocol stack 
including an IP layer, a transport layer, a sockets layer, and an application layer and which, for 
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said inbound packet, said IP layer provides to said transport layer said inbound packet and 
receives back from said transport layer indicia, provided to said transport layer by said sockets 
layer, identifying the application layer application to which said packet would have been 
delivered as provided by Jackowski. Here the combination satisfies the need for a system that 
prioritizes network traffic based on high-level applications and users rather than low-level IP 
addresses and TCP ports. See Jackowski, column 4, lines 38-48. This rationale also applies to 
those dependent claims utilizing the same combination. 

11. Concerning claims 1,10, 22, 24, 29, 34, 36, 37, 39, 41, 43, 45, 47, 49, 50, and 52, 
Lucovsky did not explicitly state filter processing including constructing and evaluating logical 
expressions of arbitrary length, and selectively using a set of logical operators, alternative filter 
selector fields, and value set. However, such filter constructions are well known in the art as 
evidenced by Jackowski whose system uses dynamic policy rules in order to classify packets. It 
would have been obvious to one of ordinary skill in the art at the time of the applicant's 
invention to modify the system of Lucovsky by adding the ability to utilize filter processing 
including constructing and evaluating logical expressions of arbitrary length, and selectively 
using a set of logical operators, alternative filter selector fields, and value set as provided by 
Jackowski. Again the combination satisfies the need for a system that prioritizes network traffic 
based on high-level applications and users rather than low-level IP addresses and TCP ports. See 
Jackowski, column 4, lines 38-48. This rationale also applies to those dependent claims utilizing 
the same combination. 

12. Concerning claims 1, 10, 22, 25, 30, 34, 36, 37, 39, 41, 43, 45, 48, 49, and 53, Lucovsky 
does not explicitly state marking a packet as non-deliverable. However, taking some action on a 
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packet before passing it on for farther filtering is well known in the art and Lucovsky has 
disclosed a variety of features that could be used for such an action. In one instance Lucovsky 
discusses values that uniquely identify each process. See column 5, lines 18-24. For example, a 
packet could be marked as non-deliverable before being passed to the sockets layer if its data 
does not correctly identify a certain value of a certain process. Also, authentication or 
authorization techniques are well known in the art that may lead to a pre-assessment of a packet 
before it is passed to the sockets layer. Thus, it would have been obvious to one of ordinary skill 
in the art at the time of the applicant's invention to modify the system of Lucovsky by adding the 
ability to mark a packet as non-deliverable. 

13. Thereby, the combination of Lucovsky and Jackowski discloses: 
• <Claim 1> 

A method for control and management of communication traffic, comprising the steps of: 
expressing access rules as filters referencing system kernel data (Lucovsky, column 2, 
lines 13-35); for outbound processing, determining source application indicia (Lucovsky, 
column 7, lines 51-65); for inbound packet processing, executing a look-ahead function 
to determine target application indicia; said look-ahead function being executed within a 
protocol stack including an IP layer, a transport layer, a sockets layer, and an application 
layer and which, for said inbound packet, said IP layer provides to said transport layer 
said inbound packet, marked as non-deliverable, and receives back from said transport 
layer indicia, provided to said transport layer by said sockets layer, identifying the 
application layer application to which said packet would have been delivered (Lucovsky, 
column 8, lines 23-32 and Jackowski, column 15, line 66 through column 16, line 32); 
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and responsive to said source or target application indicia, executing filter processing; 
said filter processing including constructing and evaluating logical expressions of 
arbitrary length, and selectively using a set of logical operators, alternative filter selector 
fields, and value set (Lucovsky, column 8, lines 11-16 and 33-40 and Jackowski, column 
15, lines 21-43; column 11, lines 41-46; and column 12, line 61 through column 13, line 
7). 

• <Claim 2> 

The method of claim 1, wherein said protocol stack is a TCP/IP protocol stack, and 
further comprising the steps of executing said determining and executing steps within a 
kernel filtering function upon encountering a filter selector field referencing kernel data 
not included in said packet (Lucovsky, column 8, lines 17-22). 

• <Claim 3> 

The method of claim 1 , wherein said protocol stack is a TCP/IP protocol stack, and said 
filter processing including the steps of: determining a task or thread identifier (Lucovsky, 
figure 2, items 101 and 102); based on said task or thread identifier, determining a 
process or job identifier (Lucovsky, column 4, lines 53-59); and based on said process or 
job identifier, determining job or process attributes for filter processing (Lucovsky, 
column 7, lines 6-1 1 and figure 2, items 119 and 120). 

• <Claim 4> 

The method of claim 1 , wherein said protocol stack is a TCP/IP protocol stack, and said 
filter processing including the steps of: determining a user identifier (Lucovsky, column 
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4, lines 53-59); and based on said user identifier, determining user attributes for filter 
processing (Lucovsky, column 7, lines 6-1 1 and figure 2, items 1 19 and 120). 

• <Claim5> 

The method of claim 3, further comprising the step of determining from said task 
identifier a work control block containing said process or job identifier (Jackowski, 
column 12, lines 15-29). 

• <Claim 8> 

The method of claim 1 , wherein said protocol stack is a TCP/IP protocol stack, and 
further comprising the steps of: delivering to said filters infrastructure access rules for 
defining security context (Lucovsky, column 1, lines 44-58 and column 2, lines 36-48). 

• <Claim 9> 

The method of claim 8, said infrastructure including logging, auditing, and filter rule load 
controls (Jackowski, column 11, line 41 through column 12, line 14). 

• <Claim 10> 

A method for control and management of aspects of communication traffic within 
filtering, comprising the steps of: receiving IP packet data into a TCP/IP protocol stack 
executing within a system kernel (Lucovsky, column 2, lines 13-35); for inbound packet 
processing, executing a look-ahead function within a protocol stack including an IP layer, 
a transport layer, a sockets layer, and an application layer and which, for said IP inbound 
packet, said IP layer provides to said transport layer said inbound IP packet, marked as 
non-deliverable, and receives back from said transport layer indicia, provided to said 
transport layer by said sockets layer, identifying the application layer application to 
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which said packet would have been delivered (Lucovsky, column 8, lines 23-32 and 
Jackowski, column 15, line 66 through column 16, line 32); and executing filtering code 
within said system kernel with respect to non-IP packet data accessed within said system 
kernel outside of said TCP/IP protocol stack (Lucovsky, column 8, lines 11-16 and 33- 
40); said filtering code constructing and evaluating logical expressions of arbitrary 
length, and selectively using a set of logical operators, alternative filter selector fields, 
and value set (Jackowski, column 15, lines 21-43; column 1 1, lines 41-46; and column 
12, line 61 through column 13, line 7). 

• <Claimll> 

The method of claim 10, said non-IP packet data including context data regarding said IP 
packet (Lucovsky, column 8, lines 23-32). 

• <Claim 12> 

The method claim 10, said non-IP packet data including data specific to a task generating 
said non-IP packet data (Lucovsky, column 7, lines 51-65). 

• <Claim 13> 

The method of claim 10, said non-IP packet data including data specific to a task that will 
receive said IP packet (Lucovsky, column 8, lines 23-32). 

• <Claim 14> 

The method of claim 1 1 , said context data including packet arrival interface indicia 
(Lucovsky, column 8, lines 23-32). 



Application/Control Number: 09/919,185 Page 9 

Art Unit: 2152 

• <Claim 22> 

A method for traversing a portion only of a protocol stack to disallow selective IP packet 
traffic, comprising the steps of: receiving a packet in the kernel. of the operating system of 
a first node from an application, said kernel including filter processor (Lucovsky, column 
2, lines 13-35); said filter processor for constructing and evaluating logical expressions of 
arbitrary length, said logical expressions selectively including a set of logical operators, 
alternative filter selector fields, and value set (Jackowski, column 15, lines 21-43; column 
11, lines 41-46; and column 12, line 61 through column 13, line 7); for inbound packet 
processing to a first node from a second node, executing a look-ahead function in the 
system kernel of said first node to determine a target application; said system kernel 
including a TCP/IP protocol stack including an IP layer, a transport layer, a sockets layer, 
and an application layer and which, for said inbound packet, said IP layer provides to said 
transport layer said inbound packet, marked as non-deliverable, and receives back from 
said transport layer indicia identifying the application layer application to which said 
packet would have been delivered (Lucovsky, column 8, lines 23-32 and Jackowski, 
column 15, line 66 through column 16, line 32); for both said inbound packet processing, 
and for outbound packet processing from said first node to said second node, executing 
within said kernel the steps of processing said packet by determining a task ID 
(Lucovsky, figure 2, items 101 and 102); responsive to said task ID, determining a 
corresponding work control block (Jackowski, column 12, lines 15-29); determining a 
user process or job identifier from said work control block (Lucovsky, column 4, lines 
53-59 and Jackowski, column 12, lines 15-29)); from the user process or job identifier 
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selectively determining attributes for said user process or job (Lucovsky, column 7, lines 
6-1 1 and figure 2, items 1 19 and 120); and passing said attributes to said filter processor 
for managing and controlling communication traffic (Lucovsky, column 8, lines 11-16 
and 33-40). 

• <Claim 24> 

A method for managing and controlling communication traffic by centralizing access 
rules in filters executing within and referencing data available in system kernels, 
comprising the steps for outbound packet processing from a first node to a second node 
of: receiving said packet in the kernel of the operating system of said first node from an 
application or process at said first node (Lucovsky, column 7, lines 51-65); processing 
said packet by determining a task ID (Lucovsky, figure 2, items 101 and 102); responsive 
to said task ID, determining a corresponding work control block (Jackowski, column 12, 
lines 15-29); responsive to said work control block, determining a process or job 
identifier (Lucovsky, column 4, lines 53-59); responsive to said process job identifier, 
determining job or process attributes (Lucovsky, column 7, lines 6-1 1 figure 2, items 1 19 
and 120). 

• <Claim 25> 

The method of claim 24, further comprising the steps for inbound packet processing from 
said second node to said first node of: initially operating said kernel at said first node to 
determine a target application for said packet at said first node by executing a look-ahead 
function within a protocol stack including an IP layer, a transport layer, a sockets layer, 
and an application layer and which, for said inbound packet, said IP layer provides to said 
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transport layer said inbound packet, marked as non-deliverable, and receives back from 
said transport layer indicia, provided to said transport layer by said sockets layer, 
identifying the application layer application to which said packet would have been 
delivered (Lucovsky, column 8, lines 23-32 and Jackowski, column 15, line 66 through 
column 16, line 32). 
• <Claim 29> 

A method for managing and controlling communication traffic by centralizing the access 
rules, comprising the steps for outbound packet processing from a first node to a second 
node of: receiving said packet in the kernel of the operating system of said first node 
from an application or process at said first node, said kernel including a filter processor 
for constructing and evaluating logical expressions of arbitrary length, said logical 
expressions selectively including a set of logical operators, alternative filter selector 
fields, and value set (Lucovsky, column 7, lines 51-65 and Jackowski, column 15, lines 
21-43; column 11, lines 41-46; and column 12, line 61 through column 13, line 7); 
processing said packet within a TCP/IP stack (Jackowski, column 15, line 66 through 
column 16, line 32); by determining a task ID (Lucovsky, figure 2, items 101 and 102); 
responsive to said task ID, determining a corresponding work control block (Jackowski, 
column 12, lines 15-29); determining a user ID control block from said work control 
block (Lucovsky, column 4, lines 53-59); from the user ID control block determining 
attributes for said user (Lucosky, column 7, lines 6-1 1 and figure 2, items 119 and 120); 
and passing said attributes to said filter processor for managing and controlling 
communication traffic (Lucovsky, column 8, lines 11-16 and 33-40). 
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• <Claim 30> 

The method of claim 29, further comprising the steps for inbound packet processing from 
said second node to said first node of: initially operating said kernel at said first node to 
determine a target application for said packet at said first node by executing a look-ahead 
function within said TCP/IP protocol stack including an IP layer, a transport layer, a 
sockets layer, and an application layer and which, for said inbound packet, said IP layer 
provides to said transport layer said inbound packet, marked as non-deliverable, and 
receives back from said transport layer indicia, provided to said transport layer by said 
sockets layer, identifying the application layer application to which said packet would 
have been delivered (Lucovsky, column 8, lines 23-32 and Jackowski, column 15, line 66 
through column 16, line 32). 

• <Claim 34> 

A method for control and management of communication traffic with respect to a system 
node, comprising the steps of: receiving at said system node an inbound packet 
(Lucovsky, column 8, lines 23-32); and executing within a protocol stack of the system 
kernel of said system node a filtering function identifying for said inbound packet a filter 
referencing non-packet data, and constructing and evaluating logical expressions of 
arbitrary length, said logical expressions selectively including a set of logical operators, 
alternative filter selector fields, and value set (Lucovsky, column 2, lines 13-35 and 
Jackowski, column 15, lines 21-43; column 11, lines 41-46; and column 12, line 61 
through column 13, line 7); and responsive to said filter, executing a look-ahead function 
for identifying a target application for said inbound packet; said look-ahead function 
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executed within a protocol stack including an IP layer, a transport layer, a sockets layer, 
and an application layer and which, for said IP inbound packet, said IP layer provides to 
said transport layer said inbound packet, marked as non-deliverable, and receives back 
from said transport layer indicia, provided to said transport layer by said sockets layer, 
identifying the application layer application to which said packet would have been 
delivered (Lucovsky, column 8, lines 23-32 and Jackowski, column 15, line 66 through 
column 16, line 32). 

• <Claim35> 

The look-ahead function of the method of claim 34 wherein said protocol stack is a 
TCP/IP protocol stack, and further comprising the steps of: passing to a transport layer 
function identified by an IP header a packet marked non-deliverable for determining 
which user-level process or job is to receive said packet (Jackowski, column 12, lines 15- 
29 and obviousness as discussed above); receiving from said transport layer an 
application layer task identifier said user-level process or job (Lucovsky, column 8, lines 
23-32 and figure 2, items 101 and 102); and thereafter passing said packet marked by said 
task identifier to said transport layer for delivery to said application layer task (Lucovsky, 
column 8, lines 33-40). 

• <Claim 36> 

System for control and management of communication traffic, comprising: a system 
kernel including a filter function and stack data (Lucovsky, column 2, lines 13-35); said 
filter function including a filter selectively referencing said stack data for expressing 
access rules (Lucovsky, column 2, lines 13-35); said filter function being responsive to 
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receipt of an outbound packet determining a source application (Lucovsky, column 7, 
lines 51-65); said filter function being responsive to receipt of an inbound packet 
processing for executing a look-ahead function within a TCP/IP protocol stack to 
determine a target application; said protocol stack including an IP layer, a transport layer, 
a sockets layer, and an application layer and which, for said inbound packet, said IP layer 
provides to said transport layer said inbound packet, marked as non-deliverable, and 
receives back from said transport layer indicia, provided to said transport layer by said 
sockets layer, identifying the application layer application to which said packet would 
have been delivered (Lucovsky, column 8, lines 23-32 and Jackowski, column 15, line 66 
through column 16, line 32); and said filter function being responsive to said source or 
target application for executing filter processing including constructing and evaluating 
logical expressions of arbitrary length, said logical expressions selectively including a set 
of logical operators, alternative filter selector fields, and value set (Lucovsky, column 8, 
lines 1 1-16 and 33-40 and Jackowski, column 15, lines 21-43; column 11, lines 41-46; 
and column 12, line 61 through column 13, line 7). 
• <Claim 37> 

A system for control and management of aspects of communication traffic within 
filtering, comprising: a system kernel (Lucovsky, column 2, lines 13-35); a protocol stack 
including an IP layer, a transport layer, a sockets layer, and an application layer for 
executing within said system kernel, responsive to an inbound IP packet, a look-ahead 
function by which said IP layer provides to said transport layer said inbound IP packet, 
marked as non-deliverable, and receives back from said transport layer indicia, provided 



Application/Control Number: 09/9 19,185 Page 1 5 

Art Unit: 2152 

to said transport layer by said sockets layer, identifying the application layer application 
to which said packet would have been delivered (Lucovsky, column 8, lines 23-32 and 
Jackowski, column 15, line 66 through column 16, line 32); and filtering code within said 
system kernel operable with respect to non-IP packet data accessed within said system 
kernel outside of said protocol stack for controlling and managing said aspects of 
communication traffic (Lucovsky, column 2, lines 13-35); said filtering code for 
constructing and evaluating logical expressions of arbitrary length, said logical 
expressions selectively including a set of logical operators, alternative filter selector 
fields, and value set (Jackowski, column 15, lines 21-43; column 11, lines 41-46; and 
column 12, line 61 through column 13, line 7). 
• <Claim 39> 

A system for traversing a portion only of a TCP/IP protocol stack to disallow selective IP 
packet traffic, comprising: a system kernel (Lucovsky, column 2, lines 13-35); a filter 
processor executing within said system kernel for constructing and evaluating logical 
expressions of arbitrary length, said logical expressions selectively including a set of 
logical operators, alternative filter selector fields, and value set (Lucovsky, column 2, 
lines 13-35 and Jackowski, column 15, lines 21-43; column 1 1, lines 41-46; and column 
12, line 61 through column 13, line 7); said filter processor responsive to an inbound 
packet for executing a look-ahead function for determining a target application; said 
look-ahead function operating within said TCP/IP protocol stack including an IP layer, a 
transport layer, a sockets layer, and an application layer and which, for said IP inbound 
packet, said IP layer provides to said transport layer said inbound IP packet, marked as 
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non-deliverable, and receives back from said transport layer indicia, provided to said 
transport layer by said sockets layer, identifying the application layer application to 
which said packet would have been delivered (Lucovsky, column 8, lines 23-32 and 
Jackowski, column 15, line 66 through column 16, line 32); said filter processor 
responsive to both inbound and outbound packets for processing said packet by 
determining a task ID (Lucovsky, figure 2, items 101 and 102); responsive to said task 
ID, determining a corresponding work control block (Jackowski, column 12, lines 15-29); 
determining a user ID, process or job identifier from said work control block (Lucovsky, 
column 4, lines 53-59); from the user ID, process or job identifier selectively determining 
attributes for said user process or job (Lucovsky, column 7, lines 6-1 1 and figure 2, items 
119 and 120); and passing said attributes to said filter processor for managing and 
controlling communication traffic (Lucovsky, column 8, lines 11-16 and 33-40). 
• <Claim41> 

A system for managing and controlling communication traffic by centralizing access 
rules in filters executing within and referencing data available in system kernels, 
comprising: a computer readable medium; first code for receiving a packet in the kernel 
of the operating system of a first node from an application or process at said first node; 
said kernel responsive to an inbound packet for executing a look-ahead function within a 
TCP/IP protocol stack including an IP layer, a transport layer, a sockets layer, and an 
application layer and which, for said inbound packet, said IP layer provides to said 
transport layer said inbound IP packet, marked as non-deliverable, and receives back 
from said transport layer indicia, provided to said transport layer by said sockets layer, 
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identifying the application layer application to which said packet would have been 
delivered (Lucovsky, column 8 5 lines 23-32 and Jackowski, column 15, line 66 through 
column 16, line 32); second code for processing said packet by determining a task ID 
(Lucovsky, figure 2, items 101 and 102); third code responsive to said task ID for 
determining a corresponding work control block (Jackowski, column 12, lines 15-29); 
fourth code responsive to said work control block for determining a process or job 
identifier (Lucovsky, column 4, lines 53-59); fifth code responsive to said process or job 
identifier for determining job or process attributes (Lucovsky, column 7, lines 6-1 1 and 
figure 2, items 119 and 120); sixth code for executing said filters by constructing and 
evaluating logical expressions of arbitrary length, said logical expressions selectively 
including a set of logical operators, alternative filter selector fields, and value set 
(Jackowski, column 15, lines 21-43; column 11, lines 41-46; and column 12, line 61 
through column 13, line 7); and wherein said first, second, third, fourth, fifth, and sixth 
code is recorded on said computer readable medium. 
• <Claim 43> 

A system for control and management of communication traffic with respect to a system 
node, comprising: a filtering function executing within a protocol stack of the system 
kernel of said system node identifying for an inbound packet a filter referencing non- 
packet data (Lucovsky, column 2, lines 13-35 and column 8, lines 23-32); and a look- 
ahead function responsive to said filter for identifying a target application for said 
inbound packet; said look-ahead function functioning within a protocol stack including 
an IP layer, a transport layer, a sockets layer, and an application layer and which, for said 
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inbound packet, said IP layer provides to said transport layer said inbound packet, 
marked as non-deliverable, and receives back from said transport layer indicia, provided 
to said transport layer by said sockets layer, identifying the application layer application 
to which said packet would have been delivered (Lucovsky, column 8, lines 23-32 and 
Jackowski, column 15, line 66 through column 16, line 32); ; and a filter processor for 
constructing and evaluating logical expressions of arbitrary length, said logical 
expressions selectively including a set of logical operators, alternative filter selector 
fields, and value set (Jackowski, column 15, lines 21-43; column 11, lines 41-46; and 
column 12, line 61 through column 13, line 7). 
• <Claim 45> 

A computer program product for control and management of aspects of communication 
traffic within filtering, said computer program product comprising: a computer readable 
medium; first program instructions to receive IP packet data into a TCP/IP protocol stack 
executing within a system kernel (Lucovsky, column 2, lines 13-35) including, for 
processing an inbound IP packet, a look-ahead function within a protocol stack including 
an IP layer, a transport layer, a sockets layer, and an application layer and which, for said 
IP inbound packet, said IP layer provides to said transport layer said inbound packet, 
marked as non-deliverable, and receives back from said transport layer indicia, provided 
to said transport layer by said sockets layer, identifying the application layer application 
to which said packet would have been delivered (Lucovsky, column 8, lines 23-32 and 
Jackowski, column 15, line 66 through column 16, line 32); second program instructions 
to execute filtering code within said system kernel with respect to non-IP packet data 
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accessed within said system kernel outside of said TCP/IP protocol stack (Lucovsky, 
column 8, lines 11-16 and 33-40) by constructing and evaluating logical expressions of 
arbitrary length, said logical expressions selectively including a set of logical operators, 
alternative filter selector fields, and value set (Jackowski, column 15, lines 21-43; column 
11, lines 41-46; and column 12, line 61 through column 13, line 7); and wherein said first 
and second program instructions are recorded on said medium. 
• <Claim 47> 

A computer program product for managing and controlling communication traffic by 
centralizing access rules in filters executing within and referencing data available in 
system kernels, said computer program product comprising: a computer readable 
medium; first program instructions to receive said packet in the kernel of the operating 
system of said first node from an application or process at said first node (Lucovsky, 
column 7, lines 51-65); second program instructions to process said packet by 
determining a task ID (Lucovsky, figure 2, items 101 and 102); third program 
instructions, responsive to said task ID, determining a corresponding work control block 
(Jackowski, column 12, lines 15-29); fourth program instructions, responsive to said 
work control block, to determine a process or job identifier (Lucovsky, column 4, lines 
53-59); fifth program instructions, responsive to said process or job identifier, to 
determine job or process attributes (Lucovsky, column 7, lines 6-1 1 and figure 2, items 
119 and 120); and sixth program instructions to execute a filter processor for constructing 
and evaluating logical expressions of arbitrary length, said logical expressions selectively 
including a set of logical operators, alternative filter selector fields, and value set 
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(Jackowski, column 15, lines 21-43; column 11, lines 41-46; and column 12, line 61 
through column 13, line 7); and wherein said first, second, third, fourth, fifth, and sixth 
program instructions are recorded on said medium. 

• <Claim 48> 

The computer program product of claim 47, wherein said protocol stack is a TCP/IP 
protocol stack, and said computer program product further comprising for inbound packet 
processing from said second node to said first node: sixth program instructions to initially 
operate said kernel at said first node to determine a target application for said packet at 
said first node by executing a look-ahead function within a protocol stack including an IP 
layer, a transport layer, a sockets layer, and an application layer and which, for said IP 
inbound packet, said IP layer provides to said transport layer said inbound IP packet, 
marked as non-deliverable, and receives back from said transport layer indicia, provided 
to said transport layer by said sockets layer, identifying the application layer application 
to which said packet would have been delivered (Lucovsky, column 8, lines 23-32 and 
Jackowski, column 15, line 66 through column 16, line 32); and wherein said sixth 
program instructions are recorded on said medium. 

• <Claim 49> 

A computer program product for control and management of communication traffic, 
comprising: a computer readable medium; first program instructions for expressing 
access rules as filters referencing system kernel data (Lucovsky, column 2, lines 13-35); 
second program instructions, for outbound processing, for determining a source 
application (Lucovsky, column 7, lines 51-65); third program instructions, for inbound 
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packet processing, for executing a look-ahead function to determine a target application; 
said look-ahead function operating within a protocol stack including an IP layer, a 
transport layer, a sockets layer, and an application layer and which, for said IP inbound 
packet, said IP layer provides to said transport layer said inbound IP packet, marked as 
non-deliverable, and receives back from said transport layer indicia, provided to said 
transport layer by said sockets layer, identifying the application layer application to 
which said packet would have been delivered (Lucovsky, column 8, lines 23-32 and 
Jackowski, column 15, line 66 through column 16, line 32); fourth program instructions, 
selectively responsive to said source and target application, for executing filter processing 
including constructing and evaluating logical expressions of arbitrary length, said logical 
expressions selectively including a set of logical operators, alternative filter selector 
fields, and value set (Lucovsky, column 8, lines 11-16 and 33-40 and Jackowski, column 
15, lines 21-43; column 11, lines 41-46; and column 12, line 61 through column 13, line 
7); and wherein said first, second, third, and fourth program instructions are recorded on 
said computer readable medium. 
• <Claim 50> 

A computer program product for control and management of aspects of communication 
traffic within filtering, comprising: a computer readable medium; first program 
instructions for receiving IP packet data into a TCP/IP protocol stack executing within a 
system kernel (Lucovsky, column 2, lines 13-35) second program instructions for 
executing filtering code within said system kernel with respect to non-IP packet data 
accessed within said system kernel outside of said TCP/IP protocol stack (Lucovsky, 
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column 8 5 lines 11-16 and 33-40); said filtering code constructing and evaluating logical 
expressions of arbitrary length, said logical expressions selectively including a set of 
logical operators, alternative filter selector fields, and value set (Jackowski, column 15, 
lines 21-43; column 11, lines 41-46; column 12, line 61 through column 13, line 7); and 
wherein said first and second program instructions are recorded on said computer 
readable medium. 
• <Claim 52> 

A computer program product for managing and controlling communication traffic by 
centralizing access rules in filters executing within, and referencing data available in, 
system kernels, comprising: a computer readable medium; first program instructions for 
receiving said packet in the kernel of the operating system of said first node from an 
application or process at said first node (Lucovsky, column 7, lines 51-65); second 
program instructions for processing said packet by determining a task ID (Lucovsky, 
figure 2, items 101 and 102); third program instructions, responsive to said task ID, for 
determining a corresponding work control block (Jackowski, column 12, lines 15-29); 
fourth program instructions, responsive to said work control block, for determining a 
process or job identifier (Lucovsky, column 4, lines 53-59); fifth program instructions, 
responsive to said process or job identifier, for determining job or process attributes 
(Lucovsky, column 7, lines 6-11 and figure 2, items 119 and 120); sixth program 
instructions for executing a filter processor for constructing and evaluating logical 
expressions of arbitrary length, said logical expressions selectively including a set of 
logical operators, alternative filter selector fields, and value set (Jackowski, column 15, 
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lines 21-43; column 1 1, lines 41-46; and column 12, line 61 through column 13, line 7); 
and wherein said first, second, third, fourth, fifth, and sixth program instructions are 
recorded on said computer readable medium, 
• <Claim 53> 

The computer program product of claim 52, further comprising for inbound packet 
processing from said second node to said first node: seventh program instructions initially 
operating said kernel at said first node to determine a target application for said packet at 
said first node by executing a look-ahead function within a protocol stack including an IP 
layer, a transport layer, a sockets layer, and an application layer and which, for said IP 
inbound packet, said IP layer provides to said transport layer said inbound IP packet, 
marked as non-deliverable, and receives back from said transport layer indicia, provided 
to said transport layer by said sockets layer, identifying the application layer application 
to which said packet would have been delivered (Lucovsky, column 8, lines 23-32 and 
Jackowski, column 15, line 66 through column 16, line 32); ; and wherein said seventh 
program instructions are recorded on said computer readable medium. 
Since the combination of Lucovsky and Jackowski discloses all of the above limitations, claims 
1-5, 8-14, 22, 24, 25, 29, 30, 34-37, 39, 41, 43, 45, 47-50, 52, and 53 are rejected. 

14. Claims 18-21, 23, 38, 40, 46, and 51 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Lucovsky in view of Jackowski, as applied above, further in view of Fiveash 
et al. (U.S. Patent Number 6,076,168), hereinafter referred to as Fiveash. 
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15. The combination of Lucovsky and Jackowski disclosed a system for packet filtering 
based on a process attribute and high-level application. In an analogous art, Fiveash disclosed a 
method for securing data traffic between host systems that uses a filter having rules associated 
with a defined tunnel. 

16. Concerning claim 21, the combination of Lucovsky and Jackowski does not explicitly 
state establishing a tunnel between two IP addresses. However, Lucovsky does discuss 
processes that operate between two unique port numbers. Furthermore, Fiveash 5 s system is 
based on the use of a tunnel bound at each end to keep data confidential. It would have been 
obvious to one of ordinary skill in the art at the time of the applicant's invention to modify the 
combination of Lucovsky and Jackowski by adding the ability to establish a tunnel between two 
IP addresses as provided by Fiveash. Here the combination satisfies the need for a filter 
mechanism that can determine whether a process having a certain attribute may access a 
network. See Lucovsky, column 2, lines 5-10. 

17. Concerning claims 18, 23, 38, 40, 46, and 51, the combination of Lucovsky and 
Jackowski does not explicitly state the use of a filter statements syntax. Although Jackowski 
states the use of various parameters and values that are collected and utilized by his policy 
server, he does not set forth a specific syntax for analysis of the data. However, packet filtering 
systems that allow users to provide the parameters by using a filter statements syntax are well 
known in the art as evidenced by Fiveash. Fiveash states an exemplary list of rules that are used 
for filtering packets where the parameters of the rules are set by the user of the host system. See 
figure 4. It would have been obvious to one of ordinary skill in the art at the time of the 
applicant's invention to modify the combination of Lucovsky and Jackowski by adding the 
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ability to provide filter statements syntax as provided by Fiveash. Again the combination 
satisfies the need for a filter mechanism that can determine whether a process having a certain 
attribute may access a network. See Lucovsky, column 2, lines 5-10. 
18. Thereby, the combination of Lucovsky, Jackowski, and Fiveash discloses: 
• <Claiml8> 

A method for centralizing system-wide communication management and control within 
filter rules, comprising the steps of: providing filter statements syntax for accepting 
parameters in the form of a selector, each selector specifying selector field, operator, and 
a set of values (Fiveash, figure 4); for an inbound packet, executing a look-ahead function 
within a protocol stack including an IP layer, a transport layer, a sockets layer, and an 
application layer and which, for said inbound packet, said IP layer provides to said 
transport layer said inbound packet, marked as non-deliverable, and receives back from 
said transport layer indicia, provided to said transport layer by said sockets layer, 
identifying the application layer application to which said packet would have been 
delivered by said sockets layer (Lucovsky, column 8, lines 23-32 and Jackowski, column 
15, line 66 through column 16, line 32); said selector referencing data that does not exist 
in IP packets (Lucovsky, column 2, lines 13-35); processing said filter statements, 
including contracting and evaluating logical expressions of arbitrary length, and 
selectively using a set of logical operators, alternative filter selector fields, and value set 
(Jackowski, column 15, lines 21-43; column 11, lines 41-46; and column 12, line 61 
through column 13, line 7). 
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• <Claim 19> 

The method of claim 18, wherein said protocol stack is a TCP/IP protocol stack, and said 
parameters selectively including userid, user profile, user class, user group, user group 
authority, user special authority, job name, process name, job group, job class, job 
priority, other job or process attributes, and date & time (Lucovsky, column 4, lines 53- 
59). 

• <Claim 20> 

The method of claim 18, wherein said protocol stack is a TCP/IP protocol stack, and said 
filters statements being provided within a user interface to said system (Fiveash, column 
3, lines 57-58). 

• <Claim21> 

The method of claim 18, wherein said protocol stack is a TCP/IP protocol stack, and 
further comprising the steps of: establishing a tunnel between two IP address limiting 
traffic to applications bound to ports at each end of said tunnel (Lucovsky, column 5, 
lines 6-23 and Fiveash, column 3, lines 64-67); said filtering code accessing filtering 
attributes further limiting traffic selectively to job indicia (Lucovsky, column 4, lines 53- 
59 and column 7, lines 6-11); and operating said filtering code within a kernel filtering 
function upon encountering a filter selector field referencing kernel data not included in 
said traffic (Lucovsky, column 8, lines 11-16 and 33-40). 

• <Claim 23> 

A method for expressing access rules as filters, comprising the steps of: providing a filter 
statements syntax for accepting parameters in the form of a selector, each selector 
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specifying selector field, operator, and a set of values (Fiveash, figure 4); and said 
selector referencing data that does not exist in IP packets for controlling access to an 
application (Lucovsky, column 2, lines 13-35); for an inbound packet, executing a look- 
ahead function within a protocol stack including an IP layer, a transport layer, a sockets 
layer, and an application layer and which, for said IP inbound packet, said IP layer 
provides to said transport layer said inbound IP packet, marked as non-deliverable, and 
receives back from said transport layer indicia, provided to said transport layer by said 
sockets layer, identifying the application layer application to which said packet would 
have been delivered (Lucovsky, column 8, lines 23-32 and Jackowski, column 15, line 66 
through column 16, line 32); and processing said filter statements by constructing and 
evaluating logical expressions of arbitrary length, said logical expressions selectively 
including a set of logical operators, alternative filter selector fields, and value set 
referencing said application layer application (Jackowski, column 15, lines 21-43; 
column 11, lines 41-46; and column 12, line 61 through column 13, line 7). 
• <Claim 38> 

A system for centralizing system-wide communication management and control within 
filter rules, comprising: filter statements having a syntax for accepting parameters in the 
form of a selector, each selector specifying selector field, operator, and a set of values 
(Fiveash, figure 4); said selector referencing data that does not exist in IP packets 
(Lucovsky, column 2, lines 13-35); a look-ahead function within a protocol stack 
including an IP layer, a transport layer, a sockets layer, and an application layer and 
which, for an inbound packet, said IP layer provides to said transport layer said inbound 
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packet, marked as non-deliverable, and receives back from said transport layer indicia, 
provided to said transport layer by said sockets layer, identifying the application layer 
application to which said packet would have been delivered (Lucovsky, column 8, lines 
23-32 and Jackowski, column 15, line 66 through column 16, line 32); and a filter 
processor for constructing and evaluating filter statements including logical expressions 
of arbitrary length, said logical expressions selectively including a set of logical 
operators, alternative filter selector fields, and value set (Jackowski, column 15, lines 21- 
43; column 1 1, lines 41-46; and column 12, line 61 through column 13, line 7). 
• <Claim 40> 

A system for expressing access rules as filters, comprising: filter statements for accepting 
parameters in the form of a selector, each selector specifying selector field, operator, and 
a set of values (Fiveash, figure 4); said selector referencing data that does not exist in IP 
packets controlling access to an application (Lucovsky, column 2, lines 13-35); a look- 
ahead executing within a protocol stack including an IP layer, a transport layer, a sockets 
layer, and an application layer and which, for an inbound packet, said IP layer provides to 
said transport layer said inbound packet, marked as non-deliverable, and receives back 
from said transport layer indicia, provided to said transport layer by said sockets layer, 
identifying the application layer application to which said packet would have been 
delivered (Lucovsky, column 8, lines 23-32 and Jackowski, column 15, line 66 through 
column 16, line 32); and a filter processor for constructing and evaluating said filter 
statements as logical expressions of arbitrary length, each said logical expression 
selectively including said operator selected from a set of logical operators, alternative 
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filter selector fields, and value set (Jackowski, column 15, lines 21-43; column 11, lines 
41-46; and column 12, line 61 through column 13, line 7). 
• <Claim 46> 

A computer program product for centralizing system-wide communication management 
and control within filter rules, said computer program product comprising: a computer 
readable medium; first program instructions to execute filter statements having a syntax 
for accepting parameters in the form of a selector, each selector specifying selector field, 
a logical operator selected from a set of a plurality of logical operators, and a set of 
values (Fiveash, figure 4 and Jackowski, column 15, lines 21-43; column 11, lines 41-46; 
and column 12, line 61 through column 13, line 7); and second program instructions to 
cause said selector to reference data that does not exist in IP packets (Lucovsky, column 
2, lines 13-35), said data including application layer indicia obtained for an incoming 
packet by a look-ahead function, said look-ahead function executing within a protocol 
stack including an IP layer, a transport layer, a sockets layer, and an application layer and 
which, for said IP inbound packet, said IP layer provides to said transport layer said 
inbound IP packet, marked as non-deliverable, and receives back from said transport 
layer indicia, provided to said transport layer by said sockets layer, identifying the 
application layer application to which said packet would have been delivered (Lucovsky, 
column 8, lines 23-32 and Jackowski, column 1 5, line 66 through column 16, line 32); 
and wherein said first and second program instruction are recorded on said medium. 
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• <Claim51> 

A computer program element for centralizing system-wide communication management 
and control within filter rules comprising: a computer readable medium; first program 
instructions for providing filter statements syntax for accepting parameters in the form of 
a selector, each selector specifying selector field, a logical operator, and a set of values 
(Fiveash, figure 4); second program instructions for executing filtering by constructing 
and evaluating logical expressions of arbitrary length, said logical expressions selectively 
including said logical operator selected from a set of logical operators, at least one said 
selector field, and at least one said value (Jackowski, column 15, lines 21-43; column 1 1, 
lines 41-46; and column 12, line 61 through column 13, line 7); said selector referencing 
data that does not exist in IP packets (Lucovsky, column 2, lines 13-35) including data 
obtained, for an inbound packet, by executing a look-ahead function within a protocol 
stack including an IP layer, a transport layer, a sockets layer, and an application layer and 
which, for said IP inbound packet, said IP layer provides to said transport layer said 
inbound IP packet, marked as non-deliverable, and receives back from said transport 
layer indicia, provided to said transport layer by said sockets layer, identifying the 
application layer application to which said packet would have been delivered (Lucovsky, 

♦ 

column 8, lines 23-32 and Jackowski, column 15, line 66 through column 16, line 32); 
and wherein said first and second program instructions are recorded on said computer 
readable medium. 

Since the combination of Lucovsky, Jackowski and Fiveash discloses all of the above 
limitations, claims 16-21, 23, 38, 40, 46, and 51 are rejected. 
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Response to A rguments 

1 9. In the remarks, the applicant has argued: 

• <Argument 1> 

The combination of Lucovsky and Jackowski is based on hindsight reconstruction. 

• <Argument 2> 

The combination of Lucovsky and Jackowski does not disclose the features of claim 1 
because it does not disclose "said look-ahead function being executed within a protocol 
stack" as recited in claim 1 . 

• < Argument 3> 

It would not have been obvious over Lucovsky to mark a packet as non-deliverable as 
recited in claim 1 . 

• <Argument 4> 

It would not have been obvious to combine Lucovsky, Jackowski, and Fiveash to provide 
filter statements syntax as recited in claim 18. 

20. In response to argument 1, it is maintained that the combination of Lucovsky and 
Jackowski represents a proper combination with proper motivation to combine. As previously 
stated, the combination satisfies the need for a system that prioritizes network traffic based on 
high-level applications and users rather than low-level IP addresses and TCP ports. The 
applicant has argued that Jackowski does not add this to the combination "inasmuch as 
Jackowski does not filter." First, to say Jackowski adds nothing to the combination based on the 
motivation to combine is clearly wrong as the motivation itself was taught by Jackowski. See 
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Jackowski, column 4, lines 38-48. Second, to say Jackowski does not filter is also wrong. 
Jackowski's extensible service provider performs packet filtering for the plugins. See, inter alia, 
Jackowski's claim 18. Here the combination of Lucovsky and Jackowski takes into account only 
knowledge which was within the level of ordinary skill at the time the claimed invention was 
made and does not include knowledge gleaned only from the applicants disclosure, thus the 
combination is proper. 

21 . In response to argument 2, the combination of Lucovsky and Jackowski does disclose the 
look-ahead function being executed within a TCP/IP protocol stack. The previous line citation to 
Jackowski, column 15, line 66 through column 16, line 32, clearly states the use of the extensible 
service provider within the TCP/IP protocol stack. See also Jackowski, figures 4, 5, 10, and 1 1 
which clearly show the extensible service provider within the TCP/IP protocol stack. A TCP/IP 
protocol stack is defined by all layers of the stack, not just the transport and network layers. 
Even if the applicant intended to claim the stack as only the transport and network layers, this 
would be in direct contradiction to what the claim actually states. The claims define the protocol 
stack as "including an IP layer, a transport layer, a sockets layer, and an application layer." 
Clearly Jackowski's extensible service provider functions between the sockets layer and 
transport layer and is thus within the TCP/IP protocol stack. Even if the applicant intended to 
claim the stack as only the transport and network layers, the combination of Lucovsky and 
Jackowski would still meet the limitation as Jackowski's extensible service provider functions in 
direct interaction with the transport layer. For further detail, the applicant is directed to the 
discussion of the extensible service provider at Jackowski, column 3, line 40 through column 4, 
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line 48. "Extensible service provider fits between Winsock-2 library and TCP layer, operating 
on data sent from Winsock-2 library to TCP layer for transmission." 

22. In response to argument 3, it is maintained that it would have been obvious over 
Lucovsky to mark a packet as non-deliverable. In the remarks, see pages 47 and 48, the 
applicant admits that it was well known in the art that a packet could be marked as non- 
deliverable before being passed to the sockets layer if its data does not correctly identify a certain 
process. The applicant argues that this is not what is being claimed, however the rejection 
clearly sets out that the combination of Lucovsky and Jackowski teaches the claimed look-ahead 
function and that which is obvious is the simple act of marking a packet non-deliverable. It was 
well known in the art at the time of the applicant's invention that in packet filtering systems 
packets are marked in different ways for further processing. As discussed at Lucovsky, column 
8, lines 33-46, Lucovsky teaches that his system makes the determination that a packet is non- 
deliverable, he is only silent about the actual marking. But again, this was well known in the art 
and as much was admitted by the applicant as discussed above. 

23. In response to argument 4, it is maintained that it would have been obvious to combine 
Lucovsky, Jackowski, and Fiveash to provide filter statements syntax as recited in claim 18. 
Concerning the combination, for some reason the applicant argues that "It makes more sense to 
say 'modify Lucovsky by adding the ability to filter...'." However, it is unclear how this line of 
thinking makes any sense since Lucovsky already performs packet filtering. See the previous 
line citation to Lucovsky, column 8, lines 23-32. Although the combination of Lucovsky and 
Jackowski teaches packet filtering, it is silent on a specific filter statements syntax, which is why 
Fiveash is presented in the rejection. Here the applicant also argues that "it would be unnatural 
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and non-obvious" to combine Jackowski with either Lucovsky or Fiveash because Jackowski' s 
solution is above the TCP/IP stack. However, as previously discussed, Jackowski's solution 
clearly operates within the TCP/IP stack. See the response to argument 2 above. 

24. Further, the applicant has argued that the present invention "is not obvious when Fiveash 
is combined with Lucovsky because Fiveash uses classic IP packet filtering using only IP packet 
attributes and Lucovsky uses a very different means of acquiring process attributes." However, 
it is still unclear why the applicant believes that Lucovsky does not perform IP packet filtering. 
See, inter alia, Lucovsky, column 8, lines 23-32. Also regarding this statement, the applicant is 
reminded that the rejection is based on the combination of Lucovsky, Jackowski, and Fiveash 
and not on the combination of only Lucovsky and Fiveash as has been argued here. 

25. In addition, the applicant has argued that claims rejected under 35 U.S.C. 103, but not 
explicitly discussed, are allowable based on the above arguments. Thus, claims disclosing 
similar limitations to the discussed claims and related dependent claims remain rejected under 
the same reasoning as presented above. 



Conclusion 

26. All claims are drawn to the same invention claimed in the application prior to the entry of 
the submission under 37 CFR 1.114 and could have been finally rejected on the grounds and art 
of record in the next Office action if they had been entered in the application prior to entry under 
37 CFR 1.114. Accordingly, THIS ACTION IS MADE FINAL even though it is a first action 
after the filing of a request for continued examination and the submission under 37 CFR 1.114. 
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See MPEP § 706.07(b). The applicant is reminded of the extension of time policy as set forth in 
37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 
1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, 
will the statutory period for reply expire later than SIX MONTHS from the mailing date of this 
final action. 

27. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Victor Lesniewski whose telephone number is 571-272-3987. 
The examiner can normally be reached on Monday through Thursday. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Bunjob Jaroenchonwanit can be reached on 571-272-3913. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 




